1. The Field of the Invention
The present invention generally relates to computer network security. More specifically, the present invention provides for maintaining a secure context between two applications, without having to have executable code in either application for obtaining or generating security context tokens used to secure the communication.
2. Background and Related Art
Computer systems and related technology affect many aspects of society. Indeed, the computer systems ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, database management, etc.) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another to form computer networks over which the computer systems can communicate electronically to share data. Web services has been a driving force in advancing such communications between systems and allows applications to share data, and—more powerfully—invoke capabilities from other applications without regard to how those applications were built, what operating system or platform they run on, and what devices are used to access them. Although Web services remain independent of each other, they can loosely link themselves into a collaborating group that forms a particular task. Web services are invoked over the internet by means of industry-standard protocols including SOAP (Simple Open Access Protocol), extensible Markup Language (XML), and Universal Description, Discovery and Integration (UDDI), Web Service Description Language (WSDL), etc.
Often, electronic communication on a computer network includes a client computer system (hereafter referred to as a “client”) requesting access to a network service (e.g., Web services) at a server computer system (hereinafter referred to as a “service”). Frequently, network services are protected by security mechanisms such that only trusted clients are allowed to access the network services. Thus, when requesting access to a network service, a client may be required to submit security input that includes or represents security assertions (e.g., a user I.D., a password, a digital signature, digital certificates, etc.). The service can process the submitted security input and output a security response. When the client security input is appropriate (e.g., when the client is authenticated and authorized), the service may output a security response that indicates access to the network service has been granted. On the other hand, when the client's security input is not appropriate, the service may output a security response that indicates access to the network service has been denied.
Although the use of authentication mechanisms such as digital signatures and digital certificates are generally useful for one-way messages, they are subject to several forms of attacks, e.g., recording a signed message and resending it (a reply attack). For these reasons, parties involved in a multi-message exchange typically establish a mutually authenticated security context, which refers to an established authentication state and negotiated key(s) that may have additional security-related properties. Rather than exclusively using public/private keys, this approach involves the use of a session key that is used by the parties to encrypt data that is shared between them.
Under this approach, parties exchange credentials (i.e., authenticate either mutually or unilaterally, e.g., just the client) only once, at the beginning of the conversation. If the credentials are accepted, the requester gets a security context token that acts as a lightweight credential. Subsequent messages in the conversation only have to carry this security context token, because the token implies the security context established by the initial exchange of credentials. This makes processing a secure conversation faster than processing each message individually.
Typically, a security context may be established by a client requesting the security context token from a token issuer. This request for the token will typically include the client's base token (e.g., a user name, identity, key, computing capabilities, etc.), or at least a reference thereto. Upon authentication, the issuer then issues the security context token to the client for it to use with the service. In particular, the security context token will be used to sign and/or encrypt messages, and reference the base token information, which will typically include a shared secret such as symmetrical key used for encryption and signing. Both the client and the service will use the security context token for all subsequent communication messages exchanged between them.
Although the security context token allows for faster processing, while still maintaining signing, encryption and authentication of messages, there are several drawbacks to the current security context infrastructure. For example, both the client and the service must have a significant amount of code within each application in order to utilize and maintain the security context token. For instance, the client needs to have code written in its application that will recognize that communications with the service application must use a security context token, request such token from a token issuer, provide the appropriate information within the request, save the security context token for future communications, and reference the appropriate base token and shared secret when receiving communications from the service using the security context token. Likewise, the service application must be coded such that when receiving secured messages from the client based on the security context token, the service application must be able to identify the base token, determine the appropriate session key associated with the base token to decrypt the message, save the security context token, and reuse the security context token to encrypt messages and sign them for securely delivering them to the client.
Because such implementations for security context must be coded in both the client and service applications, there is little, if any flexibility, nor ease in extending the system. For example, if it may be desirable to extend the Web services to enable it to issue security context token; however, doing such would require another large amount of code in the service application and as well as rewriting existing code. Further, because such application developers are typically not experts in such security context issues, there are security concerns that come into play, as well as performance, stress, or other robustness factors.